Conventional network elements can support various services and features such as monitoring, configuring, and protecting circuits in a network. As the numbers of services and features are added to a network element, additional management servers and server-related components will have to be added for each new service or feature to permit interaction between the network element and client devices. Additionally, a new interface will have to be added for each new service so that clients can communicate with the newly introduced service. The addition of new interfaces typically has a detrimental impact on the network element components and/or modules and on the client devices that interact with the network element. Additional design, development, and verification efforts are needed to add such new services and these additional efforts can increase the time to market of these new services.
Reference is now made to a conventional network element 300 in FIG. 1 for purposes of describing the drawbacks and disadvantages of previous approaches. Some of the drawbacks and disadvantages of the conventional network elements are as follows. Each of the different service applications (or alternatively called services) (e.g., Equipment 305, Alarms 310, Security 315, Connections 320, Performance monitoring 325, and/or Log 330) require different interface definition languages (IDLs) (e.g., Equipment IDL, Alarm IDL, User Account IDL, Connection IDL, Performance Monitoring (“PM”) IDL, and/or Log Retrieval IDL, respectively) as interface contracts between the conventional network element 300 and any client communicating to that network element 300. If additional service applications are added to the conventional network element 300, then the number of IDLs will increase, with one IDL added for each new service application. So for example, if a need arises to add protection capability to the network element 300, a new protection IDL would need to be added to the network element. To utilize this new IDL in the network element, all clients that need this capability also would have to implement this new IDL. Typically, the addition of a new IDL for each new service in the conventional network negatively affects all client devices that are coupled to the conventional network element 300. Additionally, components and/or modules on the conventional network element 300 are also typically negatively affected. For example, if the network element 300 supports fifty (50) services, then 50 IDLs may be required to be implemented. These IDL interfaces will require additional implementation (classes/programs). Thus, previous approaches have scalability problems when more functionality and complexity are added to the network elements 300.
Furthermore, these IDLs use explicit data structures and methods to express the functions of the new service being added. Hence, there is no relationship between the IDL defined for the connection service 320 and the IDL defined for protection service. This lack of a relationship, therefore, increases the development time, as each such new service results in an entirely new development effort.
This results in too much code that appears similar on both the network element 300 and the client side. However, since their IDLs have different services, functions and structures, they cannot be combined and handled in a uniform fashion.
Thus, a new method is needed to permit the addition of new services on network elements while minimizing the time to market. Another important factor that needs to be considered is the backward compatibility of the new services and enhancements to existing services. The interfaces need to be generic enough to make such enhancements easy.